Hi, I have created a set of requirements for a customer and I have provided them with the module via the RIF feature for their review. The IDs in the module I created are not sequential since I have deleted/inserted requirements throughout the module. The problem I'm having is that when the customer imports the XML file into their database, the module that they create has a sequential set of unique IDs that do not match the unique IDs I created. I'm not sure if I'm missing something in creating the XML file or if the problem is at the customer end, when importing the XML file. But, basically I need the IDs in the module I provided to match those of the module that the customer creates when importing the data. Any help on this would be very much appreciated. Thanks. Thomas DOORSnoob - Thu Apr 18 09:35:05 EDT 2013 |
Re: Retaining Unique IDs when importing XML files IBM wants to make money, so they do have a better for of xml exchange but it costs about 4000 us dollars per year for a license. Couldn't find link to it in the general forum because of the search function being out of service. But here is contact info for the product: Birgit Schoenfeld [birgit.schoenfeld@de.ibm.com] |
Re: Retaining Unique IDs when importing XML files Hi The problem of different ids in different modules is absolutely normal. If you export an object, the you have do add your id to the export file. The "other side" has to import the parameter as an attribtue like "orginalID". If they perform an export, they have to export this id too. In the home module you have to compare the "Absolute Number"-Attribute in your Module against the "originalID" in the reimport file. And be shure, that you also handle the module id in the same way, so that you can test it too. Otherwise it may be possible that you import your customer-a-data into the customer-b-database and this only will increase the bloddy preasure of some important people. Best regard Wolfgang |
Re: Retaining Unique IDs when importing XML files Wolfgang Uhr - Fri May 03 04:22:04 EDT 2013 Hi The problem of different ids in different modules is absolutely normal. If you export an object, the you have do add your id to the export file. The "other side" has to import the parameter as an attribtue like "orginalID". If they perform an export, they have to export this id too. In the home module you have to compare the "Absolute Number"-Attribute in your Module against the "originalID" in the reimport file. And be shure, that you also handle the module id in the same way, so that you can test it too. Otherwise it may be possible that you import your customer-a-data into the customer-b-database and this only will increase the bloddy preasure of some important people. Best regard Wolfgang This is another reason to not use "Object Identifier" as the "Requirement ID". |
Re: Retaining Unique IDs when importing XML files llandale - Fri May 03 12:48:55 EDT 2013 This is another reason to not use "Object Identifier" as the "Requirement ID". Little bit late replay but... Not using Object Identifier (Abs nr) completely defeats the purpose of a tool like DOORS which uses (abs nr) this to guarantee uniqueness. RIF/ReqIF just supports (is supposed to) the functionality that your export in RIF/ReqIF format includes your Req ID. This is then imported into an attribute in the 'away' database as a foreign ID (and is usually hidden from normal user views). On resend back to the Home database, this ID is returned in the export RIF/ReqIF file. On import into the Home DB, this is the key used to determine whether an object exists and needs updating or (when the attribute is empty for a row) that a new object needs to be inserted into the Home db. The concept is easy and logical but the problem is that different tool vendors do not always implement the RIF/ReqIF functionality 'thoughtfully'. |
Re: Retaining Unique IDs when importing XML files BillTidy - Thu Jun 20 05:22:16 EDT 2013 Little bit late replay but... Not using Object Identifier (Abs nr) completely defeats the purpose of a tool like DOORS which uses (abs nr) this to guarantee uniqueness. RIF/ReqIF just supports (is supposed to) the functionality that your export in RIF/ReqIF format includes your Req ID. This is then imported into an attribute in the 'away' database as a foreign ID (and is usually hidden from normal user views). On resend back to the Home database, this ID is returned in the export RIF/ReqIF file. On import into the Home DB, this is the key used to determine whether an object exists and needs updating or (when the attribute is empty for a row) that a new object needs to be inserted into the Home db. The concept is easy and logical but the problem is that different tool vendors do not always implement the RIF/ReqIF functionality 'thoughtfully'. I'm suggesting a big distinction between "Object Identifier" and "Requirement Identier". You certainly need a unique "Object Identifier" when you are copying or exporting/impotorting modules. If the thing you are representing in DOORS has a meaningful unique ID in the real world, then replacing that with object Id would be a disaster.
Imagine the disaster if you consistently use refer to the above things using Object Identifier. Now "Requirement ID" generally has no external real-world value, but it often does. Even if it doesn't, this reference only makes sense for this module in this database. Some other database could not realistically have a module representing these requirements since the ObjIDs therein do not match the original. If the original object somehow gets purged, then the "Requirement" is also gone. If you use a separate "Requirement ID" you can simply create a new object.- -Louie |
Re: Retaining Unique IDs when importing XML files llandale - Fri Jun 21 14:53:33 EDT 2013 I'm suggesting a big distinction between "Object Identifier" and "Requirement Identier". You certainly need a unique "Object Identifier" when you are copying or exporting/impotorting modules. If the thing you are representing in DOORS has a meaningful unique ID in the real world, then replacing that with object Id would be a disaster.
Imagine the disaster if you consistently use refer to the above things using Object Identifier. Now "Requirement ID" generally has no external real-world value, but it often does. Even if it doesn't, this reference only makes sense for this module in this database. Some other database could not realistically have a module representing these requirements since the ObjIDs therein do not match the original. If the original object somehow gets purged, then the "Requirement" is also gone. If you use a separate "Requirement ID" you can simply create a new object.- -Louie Certainly true but "Student ID", "MilStnd ID" and VIN are foreign IDs for DOORS. I'm not suggesting replacing them but you will make your life a whole lot easier by pairing them with the unique DOORS ID as a foreign ID in a DOORS module. We have several tools integrated with DOORS (exchanging data in batch). Each of the other domains/tools has their own unique ID (Student ID, etc) but when exchanging data with DOORS you need to have the DOORS internal ID as part of the data exchange to manage that effectively (know which rows to update and which are new rows to be inserted into DOORS). Each interface has its own key-pairs, either the DOORS ID+Student ID or DOORS ID+MilStnd ID or DOORS ID+VIN, etc. By having the DOORS ID you can very easily detect that it is a new row or a row to update (new rows to insert have no DOORS ID). Having these keypairs also lets you easily update a single object from multiple data sources. |